-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
set a default and max ttl for redis keys #38562
Conversation
a60dee9
to
d50a43b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be mentioned in developer documentation as well.
|
I think it would be reasonable to also define an upper bound for TTL. Like a cache key can only exist for three months. |
Could this applied as a patch in 24.0.7? |
d50a43b
to
5b4f615
Compare
Switched the default to 1 day as per the interface docs and added a max of 1 month |
5b4f615
to
b27b5ed
Compare
return $this->getCache()->setex($this->getPrefix() . $key, $ttl, $value); | ||
} else { | ||
return $this->getCache()->set($this->getPrefix() . $key, $value); | ||
if ($ttl === 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m a tiny bit worried that we may have code path not sending an int in $ttl since it is not strong typed, so here passing '0' would still result in infinite TTL I think?
Not sure if this worry is justified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were already checking for an int, I'd say LGTM
having infinite TTL can lead to leaked keys as the prefix changes with version upgrades Signed-off-by: Robin Appelman <robin@icewind.nl>
b27b5ed
to
cc3c7c2
Compare
having infinite TTL can lead to leaked keys as the prefix changes with version upgrades